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Beschreibung 
S ta tu spr ogr ainm 

Verfahren zum Debuggen von Programmer* fiir industrielle Steue- 
rungen und 

DEBUG-Mechanismus fur Steuerungen 

Es wird eine Funktionalitat angeboten, in der der Anwender ei- 
nen Bereich eines ST-Programmes (Programm, das in Structured 
Text geschrieben ist) markieren kann. Aktiviert er den DEBUG- 
Mechanismus, werden ihm in einem zweiten Fenster neben seiner 
ST-Quelle fur den entsprechend zyklisch durchlauf enen Pro- 
grammcode noch die Werte der im Programmcode verwendeten Vari- 
ablen konsistent fur den jeweiligen Durchlauf angezeigt. Damit 
kann er sehr gut bei zyklischer SPS-Funktionalitat Diagnose 
und Programm-Debug realisieren. Fur eine Realisierung des Me- 
chanismusses scheidet eine interpretative Losung aus Perfor- 
mance-Grunden aus . 

Fur das ST-Programm wird speziell instrumentierter Zwischenco- 
de erzeugt. Dieser Zwischencode enthalt zusatzliche Informati- 
onen mit deren Hilfe spater das Run-Time-System auf eben ver- 
wendete Variablen Riickschlusse Ziehen kann. 

Der Compiler kompiliert das ST-Programm vor dem Download in 
die Steuerung und in der Steuerung wird dieser Zwischencode 
noch mal in mikroprozessorspezif ischen Code umgesetzt. 

Diese Compiler-Funktionalitat ist im Basis-Engineeringsystem 
realisiert. Das Basis-Engineeringsystem hat in seiner Daten- 
haltung eine Zuordnungsinf ormation, welche ST-Programmzeilen 
zu welchen Zwischencodeabschnitten gehoren. Der Anwender kann 
durch grafische Markierungen eine Abschnittskennung von ST- 
Programmzeilen vornehmen, darauf aufsetzend ermittelt ein De- 
bugger den dazugehorigen Zwischencodebereich . 
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Die Zuordnung kann z.B. iiber eine Zuordnungstabelle oder einen 
Verweis erfolgen. 

I 

Auf ES-Seite (ES steht fur Engineering System) existiert somit 
ein ST-Programm mit einem kompilierten Zwischencode, wo ich e- 
ben liber diese Zuordnungstabelle jeweils zuordnen kann, wel- 
cher ST-Programmbereich welchem Zwischencodebereich ent- 
spricht. Dieser Zwischencode, der instrumentiert ist, wird 
dann ins Run-Time-System geladen. Das Run-Time-System setzt 
den Zwischencode dann noch mal in Mikroprozessorcode urn. Dann 
kann das Programm im Prinzip ablaufen, d.h. CPU kann in Run 
gehen. Der Mikroprozessorcode wird zyklisch durchlaufen. Wenn 
nun der Anwender im ST-Programm einen bestimmten Bereich mar- 
kiert, dann wird ein Auftrag an das Run-Time-System generiert, 
welcher Zwischencodebereich in Zukunft beobachtet werden soil. 
Das Run-Time ermittelt die Mikroprozessorcodebereiche aus die- 
ser Information und richtet sozusagen die Inf rastruktur fur 
eine Programmbeobachtung ein. Nachdem dieser Dienst eingerich- 
tet wurde, kann er zu ab diesem Zeitpunkt vom Anwender poten- 
ziell verwendet werden. Wird die Programmbeobachtungs f unktion 
vom Anwender explizit im Editor angestofien, wird von diesem 
Zeitpunkt an ein Beobachtungsmodul eingerichtet , das sich im 
Run-Time-System befindet. Wenn das Programm in diesen Code 
eintritt, werden die enthaltenen Variablenwerte in entspre- 
chende Datenpuffer geschrieben, und zwar so lange, wie sich 
das Programm in diesem Codebereich befindet. Wird der Score 
des Codebereichs verlassen, bekommt das Engineeringsystem (ES) 
von diesem Beobachtungsmodul eine Notification. Das Enginee- 
ringsystem holt sich den Datenpuffer zuruck. Ein Debug-Modul 
im ES ermittelt aus der Zwischencodezuordnung und diesem Da- 
tenpuffer die entsprechende Zeileninfo im ST-Programm und die 
Variablen konnen, wie vom Anwender gewunscht, angezeigt wer- 
den. Ist die Anzeige erfolgt, wird ein neuer Beobachtungsauf- 
trag fur diese eingerichtete Inf rastruktur abgesetzt, und das 
Spiel beginnt von vorne. Von vorne heiftt, der Zyklus oder die 
Flusssteuerung erfolgt eigentlich durch den Editor. Das ist 
auch so sinnvoll, weil der Anwender nicht so schnell das Pro- 
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gramm am Bildschirm verfolgen kann wie der SPS-Zyklus lauft. 
Eine Beobachtung im SPS-Zyklus wurde aufterdem nur die Run- 
Time-CPU stark belasten, wurde fur den Anwender keinen Vorteil 
bringen . 

Von existierenden Technologien unterscheidet sich der vorge- 
schlagene Mechanismus im Wesentlichen dadurch, dass auf ande- 
ren Steuerungen Hardware-Unterstiit zung notwendig war, d.h. man 
musste immer tiber irgendwelche Breakpoint-Mechanismen oder In- 
terrupts von Prozessoren das Debugging abfahren oder aber eine 
spezielle Hardware-Unterstutzung verwenden. Bei interpretativ 
arbeitenden Steuerungen wurde das Debugging bisher interpreta- 
tiv gelost, was naturlich sehr starke Lauf zeiteinf lusse hatte. 

Der grofle Vorteil der Erfindung ist, dass man hardwareunabhan- 
gig arbeiten kann und dass der Mechanismus die CPU nur genauso 
stark belastet, wie der Programmeditor eben diese Beobachtung 
uberhaupt ausnutzen kann. ( Laufzeit kostet nur das Beobachten 
des Markierten Bereiches. Genau betrachtet wird auch nur fur 
den markierten Bereich der Debugcode durchlaufen. Alle anderen 
Bereiche werden wie ohne Debugoption abgearbeitet ) 

Fur den Anwender eignet sich diese Funktionalitat und dieser 
Mechanismus sehr gut zum Debuggen zyklisch laufender Program- 
me. Aber auch Motion Tasks, die nicht zyklisch lauf en, konnen 
sehr gut beobachtet werden, Insbesondere kann durch einen zu- 
satzlichen Mechanismus der Trace Buffer schon vor Verlassen 
des Scopes abgeholt werden. Man kann dadurch z.B. ermitteln, 
wann man mit welchen Parametern in synchrone Aufrufe gerat . 
Auch zum Finden von Deadlocks in Motion Tasks eignet sich das 
Verfahren und der dazugehorige Mechanismus. 
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Patentanspruche 

1. Verfahren zum Debugger*, zur Beobachtung und zur Diagnose von 
Programmen zum Betrieb industrieller Steuerungen mit Engi- 
neering System und Runtime-System, 

gekennzeichnet, durch eine Untermenge folgender Merkmale: 

- Verwendung von Structured Text 
Instrumentierung des Structured Text Codes 
Erzeugung eines Zwischencodes 

- Markierung des relevanten Zwischencodebereiches 

- Abbildung des Zwischencodebereiches in einen Microprozessor- 
codebereiche 

- Verwendung eines Editors 

- Verwendung eines Compilers 

2, System zum Debuggen, zur Beobachtung und zur Diagnose von 
Programmen zum Betrieb industrieller Steuerungen mit Engi- 
neering System und Runtime-System, 

gekennzeichnet, durch eine Untermenge folgender Merkmale: 

- Verwendung von Structured Text 
Instrumentierung des Structured Text Codes 
Erzeugung eines Zwischencodes 

- Markierung des relevanten Zwischencodebereiches 

- Abbildung des Zwischencodebereiches in einen Microprozessor- 
codebereiche 

- Verwendung eines Editors 

- Verwendung eines Compilers 
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